Skip to content

Move O(n) operations to the initializer in exact_geodesics#201

Closed
yutanoma wants to merge 2 commits intonmwsharp:masterfrom
yutanoma:feature/faster-exact-geodesics
Closed

Move O(n) operations to the initializer in exact_geodesics#201
yutanoma wants to merge 2 commits intonmwsharp:masterfrom
yutanoma:feature/faster-exact-geodesics

Conversation

@yutanoma
Copy link
Copy Markdown

Fixed exact_geodesics so that you do not need to run O(n) operations whenever you query the geodesic path.
This is especially useful when you have a fixed mesh/geometry and want to query the geodesic path multiple times.

Summary of contribution

  • Moved geom.requireCornerAngles() and geom.requireVertexGaussianCurvatures() to the initializer
  • Added clear_data() that clears the data except the ones associated with the mesh/geometry

Usage

std::vector<SurfacePoint> p0s, p1s;
// initialize your p0s/p1s here

GeodesicAlgorithmExact mmp(mesh, geometry);

for (int i = 0; i < p0s.size(); i++) {
  auto p0 = p0s[i];
  auto p1 = p1s[i];

  mmp.propagate({p0}, GEODESIC_INF, {p1});
  std::vector<SurfacePoint> path = mmp.traceBack(p1);
  // do science with your path here

  // clear the propagated data so that you can use `mmp` for another geodesic computation
  mmp.clear_data();
}

@nmwsharp
Copy link
Copy Markdown
Owner

Hey, looks like I forgot to merge this from ages ago -- my apologies!

Looking at it now, I have a question, it's not clear to me what clear() vs the new clear_data() do? Do you remember? I want to add some guidance for the user about when to call one vs. the other.

Is it that clear_data() needs to be called when propagating from a different source set? I'm a bit confused because it seems like clear() is already called at beginning of each propagate() and resets a bunch of data.

@nmwsharp nmwsharp force-pushed the feature/faster-exact-geodesics branch from bf0d89b to 05487e4 Compare April 27, 2026 04:20
@nmwsharp
Copy link
Copy Markdown
Owner

I started to clean this up to merge, but then I realized it doesn't really make sense to me. I don't see how it improves O(n) behavior for multiple paths.

I'm going to close this for now assuming it's stale code. Just let me know if I have misunderstood and we can reopen it.

@nmwsharp nmwsharp closed this Apr 27, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants